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!  Abstract 


Two  important  factors  hindeij  our  ability  to  address  large  planning  problems.  On 
one  hand,  oy/r  understanding  o£'  planning  is  not  independent  from  specific  planning 
frameworks.  On  the  other  han<^,  current  planning  frameworks  lack  modularity,  a  key 
factor  for  “divide  and  conquer*  approaches  to  large  problems.  This  paper  addresses 
the  formal  definition  of  planning,  points  out  some  limitations  of  the  current  planning 
frameworks,  and  describes  a  new  planning  framework  that  overcomes  these  limitations. 
Our  formal  definition  relies  on  the  hypothesis  that  the  problem  solver’s  model  of  the 
world  is  a  dynamical  system.  On  this  basis,  we  can  clearly  separate  the  knowledge 
about  how  the  world  works  from  the  heuristic  knowledge  needed  to  solve  problems 
quickly.  Our  definition  is  also  independent  from  any  particular  planning  representa¬ 
tion  framework.  Our  analysis  of  modularity  indicates  which  features  can  support  it 
in  a  planning  framework.  We  describe  how  these  features  are  implemented  in  the 
HSTS  planning  framework,  a  general  purpose  facility  integrated  in  the  HSTS  schedul¬ 
ing  architecture.  Its  effectiveness  to  address  complex  “real  world*  domains  has  been 
successfully  demonstrated  on  the  problem  of  building  executable  observation  schedules 
for  the  Hubble  Space  Telescope.  /  f 


1  Introduction 


Two  important  factors  hinder  our  ability  to  address  large  planning  problems.  On  one  hand, 
our  understanding  of  planning  is  not  independent  from  specific  planning  frameworks.  On 
the  other  hand,  current  planning  frameworks  lack  modularity,  a  key  factor  for  “divide  and 
conquer”  approaches  to  large  problems. 

This  paper  addresses  the  formal  definition  of  planning,  points  out  some  limitations  of  the 
current  planning  frameworks,  and  describes  a  new  planning  framework  that  overcomes  these 
limitations. 

So  far,  the  main  efforts  to  define  planning  have  been  devoted  to  the  formal  specification  of 
planning  programs  [4].  This  is  based  on  the  widespread  agreement  that  the  data  structures 
that  these  programs  manipulate  indeed  represent  plans.  However,  it  is  also  widely  understood 
that  other  data  structures  can  represent  plans  [2].  Should  we  define  again  what  planning 
is  in  these  different  representations?  Or  should  we  try  to  give  a  representation-independent 
definition  that  can  be  applied  to  several  (and  possibly  all)  representation  frameworks? 

Another  aspect  that  is  sometimes  a  source  of  confusion  is  the  relationship  between  plan¬ 
ning  and  acting.  Traditionally,  acting  has  been  considered  the  main  justification  for  develop¬ 
ing  plans.  However,  currently  there  is  a  consensus  regarding  the  possibility  of  acting  without 
planning  [3].  In  the  same  way,  we  could  observe  that  there  can  be  planning  without  acting; 
for  example,  we  could  imagine  other  outcomes  of  the  battle  of  Waterloo  if  Napoleon  had 
made  different  decisions,  or  dream  about  how  we  would  spend  the  million  dollar  prize  of  to¬ 
morrow’s  lottery  extraction.  The  fact  is  that  planning  concerns  the  generation  of  predictions 
relative  to  a  model  of  the  world,  i.e.  a  representation  of  how  the  world  operates.  Acting,  on 
the  other  hand,  concerns  manipulating  the  real  world,  using  sensor  data  to  confirm  or  refute 
expectations  on  what  should  happen,  and  consequently,  adjusting  the  following  actions. 

The  first  part  of  the  paper  gives  a  formal  definition  of  the  planning  problem,  one  of  several 
problems  that  a  Problem  Solver  (PS)  might  address.  We  will  assume  that  PS  possesses  an 
explicit  model  of  the  temporal  operation  of  the  world  and  that  such  a  model  is  independent  of 
the  problems  that  PS  can  address  with  it.  In  particular,  we  will  restrict  our  attention  to  those 
PSs  whose  model  of  the  world  satisfies  the  axioms  of  a  dynamical  system  [8].  Well-known 
models,  like  systems  of  differential  equations  and  automata,  can  be  regarded  as  special  cases 
of  dynamical  systems.  We  define  planning  as  the  selection,  from  all  the  possible  behaviors 
of  a  dynamical  system,  of  some  of  those  that  achieve  given  goals  over  a  given  time  horizon. 

Clearly,  the  model  of  the  world  represents  only  part  of  the  knowledge  that  PS  must 
bring  to  bear  during  the  problem  solving  process.  Heuristic  knowledge  on  the  domain  will 
have  to  be  applied  in  order  to  focus  only  on  those  aspects  that  are  relevant,  and  therefore, 
to  efficiently  obtain  a  solution.  However,  these  heuristics,  which  are  problem-dependent  in 
nature,  must  be  clearly  separated  from  the  description  of  how  the  world  operates,  if  we 
want  to  build  models  of  potential  applicability  to  other  problems.  Relying  on  our  formal 
definition  of  planning,  we  will  show  how  the  lack  of  this  separation  could  lead  to  mistaking 
problem-specific  representations  for  models  of  general  applicability. 

In  Section  2  we  give  the  axiomatic  definition  of  dynamical  system,  while  in  Section  3  we 
formalize  the  planning  problem. 

In  order  to  represent  and  solve  planning  problems,  PS  needs  a  representation  framework, 
i.e.,  a  language  to  describe  models  of  the  world  and  a  data  structure  into  which  it  can  build 
plans.  While  the  definition  of  the  planning  problem  given  in  the  first  part  of  the  paper  is 
independent  from  the  representation  framework  used,  the  second  part  discusses  a  important 
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property  that  planning  representation  frameworks  should  possess  in  order  to  be  applicable 
to  large  "real  world”  domains:  modularity.  This  property  relates  to  how  a  representation 
framework  is  able  to  support  the  decomposition  of  a  model  into  elementary  components  and 
the  determination  of  the  situation  of  each  component  at  any  instant  of  time.  It  has  already 
been  noted  that  planning  frameworks  usually  lack  modularity  [9];  in  this  paper,  we  will  clearly 
identify  some  features  that  should  be  present  in  modular  representation  frameworks.  We  then 
present  the  HSTS  planning  framework  and  show  how  it  supports  modularity.  The  HSTS 
planning  framework  is  part  of  HSTS,  an  integrated  planning  and  scheduling  architecture; 
its  effectiveness  has  been  successfully  demonstrated  on  the  problem  of  building  executable 
observation  schedules  for  the  Hubble  Space  Telescope  [12]. 

Section  4  discusses  the  problem  of  modularity  while  Section  5  describes  its  solution  in 
HSTS. 

Throughout  the  article  we  will  refer  to  a  class  of  Blocks  Worlds  ( BW )  consisting  of  a 
table  supporting  a  set  of  blocks,  BLKS;  the  blocks  can  be  manipulated  either  by  a  robot 
arm  or  by  a  human  operator.  The  arm  can  find  a  given  block  and  move  it  from  one  place  to 
another,  when  it  receives  an  appropriate  command;  the  operator  can  arrange  the  blocks  on 
the  table  in  any  desired  configuration. 

2  Dynamical  Systems 

In  order  to  justify  intuitively  the  following  discussion,  we  first  sketch  the  hypothetic  cognitive 
process  from  which  PS’s  model  of  the  world  stems.  At  different  points  during  its  lifetime, 
PS  becomes  interested  in  different  portions  of  the  world  and  in  their  evolution  over  time;  we 
will  call  each  of  these  portions  a  dynamical  system.  PS  identifies  which  aspects  of  the  system 
it  wants  to  take  into  consideration  and  represents  them  as  the  state  of  the  system.  Usually 
the  system  is  not  isolated  from  the  rest  of  the  world;  PS  represents  its  knowledge  about  the 
exogenous  influences  as  the  input  to  the  system.  Finally,  PS  assumes  that  at  any  point  in 
time  the  state  is  a  function  of  the  past  history  of  both  input  and  state. 

Describing  the  world  according  to  input,  state,  and  functional  dependency  among  past 
state,  input  and  future  state  is  not  new  to  AI  [10]  and  constitutes  the  basis  of  the  modern 
theory  of  control.  To  characterize  the  models  of  the  world  that  result  from  the  previous 
cognitive  process,  we  use  the  axiomatization  from  [8]. 

Definition  1  (Dynamical  System)  A  dynamical  system  S  is  a  composite  mathemati¬ 
cal  structure: 


S  =<  T,X,UM,<p  > 

where  T ,  the  time  set,  is  an  ordered  subset  of  the  'real  numbers  7 Z,  X  is  the  state  set, 
U  is  the  set  of  input  values,  f!  =  {u(.)  :  T  —>  U}  is  a  set  of  acceptable  input  functions 
and  <p  is  the  state-transition  function: 

<p:TxTxXxSl-*X 

whose  value  is  the  state  x(t )  =  <p(t\ r,  x,  u(.))  €  X  resulting  at  time  t  from  the  initial 
state  x  =  x(r)  €  X  at  initial  time  r  €  T  under  the  action  of  the  input  u(.)  €  fi.  Additional 
axioms  further  specify  the  mathematical  structure  of  Q  and  ip  (see  [8])} 

^he  complete  axiomatization  introduces  also  the  concept  of  output  as  the  only  way  an  external  observer 
can  measure  the  state  of  the  system. 
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The  previous  definition  accounts  both  for  discrete  time  and  continuous  time  descriptions 
of  the  world,  depending  on  how  the  set  T  is  extracted  from  1Z.  Moreover,  it  does  not  privilege 
either  input  or  state  in  the  description  of  the  how  the  world  works;  both  input  and  state  are 
described  as  functions  over  the  same  time  set  T. 

The  evolution  of  the  system  can  be  experienced  by  measuring  both  the  input  and  the 
state  over  time,  i.e.,  by  perceiving  its  behavior.  More  formally: 

Definition  2  (Behavior)  A  pair  b  =<  u(.),x(.)  >,  with  u(.)  €  D  and  x(.)  :  T  — *  X ,  is  a 
behavior  of  S  if  x(t)  —  r,  i(r),  t/(.)),  for  each  t  and  r  over  which  <p  is  defined.  The 
behavior  space  B  of  S  is  the  set  of  behaviors  obtained  by  varying  t,  x(t)  and  u(.)  in  every 
possible  way. 

We  now  give  a  complete  description  of  BW  that  satisfies  the  axioms  of  Definition  1.  We 
will  use  a  STRIPS-like  representation  language. 

We  choose  Tbw  to  be  the  set  of  natural  numbers,  Af.  At  any  t  6  Af,  the  state  of  the 
system  xsw(t)  €  Xbw  is  a  list  whose  elements  can  be  any  of: 

1.  ON (t/1,2/2)  with  yx  €  BLKS,  y2  €  BLKS  U  {table}  and  y\  ^  y2; 

2.  CLEAR(yi)  with  yx  €  BLKS. 

To  represent  a  situation  physically  possible  in  Sbw,  XBw{t)  must  also  satisfy  the  following 
axioms: 

1.  Vy  1  €  BLKS,  x sw(t)  must  contain  one  and  only  one  ON(yi,y2)  (i.e.,  every  block  must 
rest  on  just  one  place); 

2.  Vy2  £  BLKS,  x B\v{t)  cannot  contain  more  than  one  ON(yi,y2)  (i.e. ,  every  block  can 
support  at  most  one  block); 

3.  Vy2  €  BLKS,  xsw(t)  contains  CLEAR(y2)  if  and  only  if  it  does  not  contain  any 
ON(yi,y2)  (i.e.,  a  block  that  does  not  support  anything  is  clear). 

Xbw  also  contains  the  special  list  [CRASH]  that  characterize  a  situation  consequent  to 
the  arm  moving  a  supporting  block. 

The  set  of  possible  inputs,  Ubw,  contains  MOVE(yi,y2),  with  y  1  €  BLKS  and  y2  € 
BLKS  U  {table},  which  represents  a  command  to  the  robot  arm,  RESTORE(i),  with  x  € 
XwBi  accounting  for  the  human  operator’s  intervention,  and  NO-OP,  the  lack  of  any  external 
influence  on  <5svv- 

We  assume  no  a  priori  restrictions  on  the  input;  therefore  f Ibw  is  the  set  of  all  the  infinite 
sequences  of  elements  from  Ubw- 

Finally,  <psw  is  defined  by  the  program  in  Figure  1. 

The  explicit  introduction  of  a  discrete  time  set  does  not  represent  a  real  novelty  with 
respect  to  the  change-based  temporization  of  classical  STRIPS-based  descriptions.  We  could 
easily  obtain  it  by  assuming  that  the  clock  is  synchronized  with  each  non-empty  input  value. 
Formally,  this  means  restricting  Qbw  to  the  set  of  sequences  formed  by  any  combination  of 
indefinite  length  of  MOVEs  and  RESTORES,  followed  only  by  NO-OPs. 

Sbw  explicitly  represents  the  undefined  state  [CRASH].  The  rationale  behind  this  is 
that,  although  we  know  that  only  one  of  the  legal  configuration  of  stacked  blocks  can  result 
from  an  “incorrect”  MOVE,  we  have  not  represented  enough  information  about  how  the  world 


XB\v{i  +  1)  :=  case  uB\v(t) 

MOVE  (yuy2): 

if  (CLEAR(yi)  €  xB\v{t))  A  (CLEAR(y2)  €  xBW(t)) 
then  x sir (0  -  [ON(yl5  y3),  CLEAR(y2)] 

+  [ON(yi,y2),CLEAR(y3)] 

else  [CRASH]; 

RESTORE(x): 

NO-OP: 

XBw(t). 


Figure  1:  State  transition  function  for  SBw  ■ 

operates  in  the  model  in  order  to  determine,  without  any  sensory  input,  an  accurate  estimate 
of  where  the  blocks  will  fall.  However,  we  cannot  avoid  to  explicitly  include  [CRASH]  in  the 
dynamical  system,  if  we  want  to  insure  the  independence  of  the  model  of  the  world  from  the 
problems  that  we  can  solve  on  it.  In  fact,  suppose  we  explicitly  represent  only  the  results 
of  “correct'1  MOVEs  (i.e.,  those  moving  a  non-supporting  block  on  a  clear  support)  [7].  A 
consequence  of  this  would  be  the  restriction  of  Qbw  to  the  sequences  that,  once  plugged  in 
<pBw,  produce  evolutions  of  the  state  without  CRASHes;  in  other  words,  QB\v  would  become 
a  function  of  <^aiv.  This  could  be  explained  easily  if  we  assumed  the  existence  of  an  actor 
that,  by  knowing  ^B\v  and  the  goal  of  excluding  CRASHes,  appropriately  restricts  Han ’• 
But  in  this  case  we  would  not  really  be  modeling  B\V  but  a  system  whose  operation  is  a 
function  of  the  solution  of  planning  problems.  This  is  clearly  at  odds  with  the  requirement 
of  independence  of  PS’s  model  of  the  world  from  the  problem  to  be  addressed. 

3  The  Planning  Problem 

Having  identified  a  portion  of  the  world  and  reoresented  it  as  a  dynamical  system,  PS  can 
now  address  a  planning  problem.  First  of  all,  PS  will  focus  its  attention  over  a  portion  of  the 
time  line  over  which  the  system  evolves;  it  will  then  consider,  of  all  the  possible  behaviors, 
those  that,  during  the  time  horizon,  achieve  certain  goals.  Achieving  all  the  goals  is  the 
criterion  that  PS  uses  to  decide  if  it  has  a  solution.  Moreover,  PS  will  also  have  preferences 
that  allow  it  to  decide,  given  any  two  solutions,  which  is  better.  Finally,  PS  itself  will  be 
operating  under  external  constraints  (e.g.,  an  actor  wanting  to  use  its  results)  that  might 
limit  the  amount  of  time  at  its  disposal  [5]. 

Formally,  we  define  a  planning  horizon  H,  an  interval  [t3,tj]  C  71,  with  t,  possibly  —  oo 
and  tj  possibly  -foo.  To  characterize  the  focusing  of  PS  to  H,  we  define  Bb  as  the  set 
obtained  by  restricting,  for  each  b  €  B,  each  component  of  b  to  Tfl  H .  We  then  define  a  goal 
T(.)  :  2Bf1  — ►  {T,F}  and  a  preference  n(.)  :  2Bh  — ►  TZ.  Finally  we  define  a  planning  deadline , 
d  €  7Z+  (possibly  -foo). 

Definition  3  (Planning  problem)  Given  a  dynamical  system  S ,  a  planning  horizon  H ,  a 
goal  T,  a  preference  n  and  a  planning  deadline  d,  find  asetVC  Bb  such  that  r('P)  ~  T  and 
Yl{V)  has  the  maximum  value  among  the  alternative  solutions  considered  within  the  deadline 
d. 
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H BW,build(x„xf )  ~  [0,+oo] 

^ Biv.build(x„xf)^^  =  [  ^6  €  V 

(u(.)  does  not  contain  RESTORES  )  A 
(x(.)  does  not  contain  CRASHes  )  A 
(x(0)  =  xa)A 

(3t j  >  0  (x(t j)  =  x j)  A  (Vt  >  tj  u(t)  =  NO-OP)  ]  A 

[Vbx  evvb2ev 

(  eliminating  all  the  NO-OPs  from  both  U6,(.)  and 
Uf,2(.),  we  obtain  the  same  sequence  of  MOVEs  )  ] 

UBw,build(T.,*/)(V)  =  -  (  number  of  MOVEs  in  any  b  €  V) 
d B\\'.build(i,,z ,)  ~ 

(a) 


^  BW,build(xt,If)^^  —  [  1^1  —  1  ]A 

[  V6  €  V 

(w(.)  does  not  contain  RESTORES  )  A 
(i(.)  does  not  contain  CRASHes  )  A 
(x(0)  =  x,)A 

(3t j  >  0  x(t j)  =  x /)  A  (Vt  >  tj  u(t)  =  NO-OP)  ] 

(b) 

Figure  2:  The  build(x3,if)  problem:  (a)  complete  formulation  on  Sbw ;  (b)  modified 
^ bw build(x,  x,)(')  k*r  a  change'bascd  description  of  D \V. 

A  plan  is  any  V  ^  0.  The  planning  problem  has  no  solution  if  and  only  if  the  empty  set 
is  the  only  one  to  satisfy  T. 

Going  back  to  Sbw  (defined  in  Section  2),  let’s  consider  the  problem  of  generating  a 
sequence  of  commands  for  the  robot  arm  to  build  a  given  block  configuration  xj,  starting 
from  a  known  initial  state  x3  (problem  build(xs,  x j)  ).  Its  formulation  requires  the  entities 
in  Figure  2  (a).  If  we  modify  Qbw  to  obtain  a  change-based  temporization  of  Sbw  (as 
described  in  Section  2),  we  can  simplify  T  gw  build(x  xf)  33  s^own  *n  Figure  2  (b). 

Different  PSs  can  use  different  representation  frameworks  (e.g.,  STRIPS-like,  temporal 
interval-based,  etc.)  to  address  the  same  planning  problem  and  can  differ  with  respect  to  the 
heuristic  knowledge  that  they  can  bring  to  bear.  Their  relative  performances  will  depend  on 
both  these  factors.  Notice  that  the  heuristic  knowledge  that  is  relevant  to  effectively  solve  a 
planning  problem  depends  on  all  the  entities  in  Definition  3.  For  example,  given  build(x, ,  x /) 
on  Sbw ,  PS  could  restrict  its  attention  to  the  portion  of  ^bw  concerning  only  “correct” 
MOVE  operations;  this  “heuristic”  can  be  easily  proved  from  the  first  two  constraints  on 
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ti(.)  and  x(.)  in  r B\vbuild(x  X)y  Although  it  is  reasonable  to  expect  that  any  PS  with  an 
adequate  level  of  “intelligence”  should  realize  this,  this  is  not  a  necessary  condition  to  have 
a  PS  that  solves  this  planning  problem. 

Other  planning  problems  could  be  easily  formulated  on  Sbw ■  For  example  we  might 
want  to  build  inputs  with  sequences  of  MOVEs  that  every  once  in  a  while  generate  a  CRASH, 
after  which  the  intervention  of  the  human  operator  RESTORES  the  blocks  configuration 
immediately  preceding  the  CRASH.  We  want  to  remark  that,  to  solve  a  planning  problem,  PS 
does  not  need  to  know-  how  its  plans  are  going  to  be  used.  A  possible  execution  environment 
for  a  plan  that  solves  the  problem  just  mentioned  could  consist  of  an  actor  that  explicitly 
sends  the  MOVE  and  RESTORE  commands  respectively  to  the  robot  arm  and  to  the  human 
operator.  But  we  could  also  imagine  that  the  actor  could  send  the  MOVE  commands  to  the 
arm  but  would  not  have  any  way  to  explicitly  request  RESTORES  from  the  human  operator. 
This  could  be  the  case  in  a  psychological  experiment  where  the  goal  of  the  actor  is  to  time 
the  performance  of  a  human  in  recognizing  and  recovering  from  errors  in  a  stream  of  actions 
of  another  agent.  The  same  plan  will  be  used  in  both  cases. 


4  The  Problem  of  Modularity 

We  now  turn  our  attention  to  the  representation  frameworks  used  in  planning,  and  to  a  prop¬ 
erty  of  theirs  that  is  highly  desirable:  modularity.  A  representation  framework  is  modular 
if  its  representation  language  adequately  supports  descriptions  of  systems  as  collections  of 
interacting  components,  and  its  plan  data  structure  allows  the  determination  of  the  situa¬ 
tion  of  each  component  at  any  instant  of  time.  Modularity  is  one  of  the  keys  to  “divide  and 
conquer”  approaches  to  modeling  and  solving  planning  problems  in  complex  “real  world” 
application  domains  [12]. 

In  this  section  we  will  show  that  current  planning  representation  frameworks  are  not 
modular;  consequently,  we  will  identify  which  structuring  features  need  to  be  added.  Modu¬ 
larization  primitives  have  been  introduced  in  activity  based  planning  frameworks  [9].  Instead, 
our  discussion  will  focus  on  explicit  representations  of  both  state  and  input,  given  that  in  a 
dynamical  system  both  input  and  state  have  equal  weight. 

We  examine  the  modularity  of  an  interval- based  STRIPS  representation  framework  [2]. 
To  conduct  our  analysis,  we  consider  a  restricted  B\V  domain  with  only  two  blocks,  a  and 
b,  and  a  robot  arm,  arm;  we  concentrate  on  the  representation  of  a  simple  plan  to  stack 
a  on  b.  The  relevant  operators  are  given  in  Figure  3  (a).  An  operator  specifies  the  facts 
that  have  to  hold  on  the  state  when  the  operator  is  applied,  and  their  temporal  relations 
with  the  action  designator;  for  example,  when  the  first  operator  is  applied,  the  time  interval 
during  which  ON(yi,  table)  holds  must  overlap  that  over  which  M0VE(yi,t/2)  occurs.  A 
database  completely  describing  the  resulting  behavior  is  depicted  in  Figure  3  (b).  Notice 
that  a  MOVE  accounts  for  the  whole  control  sequence  executed  by  arm.  With  reference  to 
Figure  3  (b),  we  can  identify  three  distinct  phases  during  MOVE(a,  b);  the  identification  of 
a  and  approach  to  it,  in  t\  <  t  <  t2,  the  grasping  of  a,  moving  to  b  and  ungrasping  of  a,  in 
t2  <  t  <  <3,  and  the  moving  away  from  a,  in  tj  <  t  <  t4. 

To  evaluate  the  modularity  of  this  representation  framework,  first  we  need  to  decide  what 
constitutes  a  primitive  system  component.  A  reasonable  initial  hypothesis  is  to  use  domain 
objects,  i.e.  the  objects  designated  by  constants  in  ground  facts.  Aside  from  requiring  the 
introduction  of  an  identifier  for  the  robot  arm  in  at  least  one  predicate  (for  example  in  MOVE 
and  NO-OP),  not  all  domain  objects  are  system  components.  Otherwise,  if  the  description 


MOVE  (y  1 .  y2) 

ON  (yi,  table),  OVERLAPS 
CLEAR  (yi),  OVERLAPS 
CLEAR  (y2),  OVERLAPS 
ON  (yi.  y2),  OVERLAPPED 
CLEAR  (yi).  OVERLAPPED 


NO-OP 


MOVE  (yi,  yi),  MEETS 
MOVE  (y3,  y4),  MET-BY 


NO-OP 


MOVE  (a,  b) 


NO-OP 


CLEAR  (a) 


CLEAR  (a) 


ON(  a,  table) 


CLEAR  (b) 


ON  (b  .table 


Figure  3:  A  simple  temporal  plan,  (a)  relevant  operators;  (b)  temporal  database. 
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of  our  domain  required  predicates  like  COLOR(a,red)  or  HEIGHT(b,3),  we  would  have  to 
consider  red  and  3  as  components  of  the  system.  Therefore,  we  need  to  declare  explicitly 
which  domain  objects  are  system  components  and  which  are  not. 

We  can  now  ask  how  easy  it  is  to  obtain  the  situation  of  all  the  system  components 
at  any  time  t.  A  simple  method  would  be  to  take  all  the  ground  facts  that  hold  in  the 
database  at  time  t  and  distribute  them  to  the  system  components  that  appear  as  their 
arguments.  So,  in  th**  example  of  Figure  3  (b),  before  1 1  the  situation  of  a  is  given  by 
CLEAR(a)  and  ON(a,  table),  while  ON(a,b)  and  ON(b,  table)  account  for  the  situation  of 
b  after  t4.  However  the  interpretation  of  MOVE(a,b)  is  not  as  straightforward.  In  fact,  while 
it  reasonably  represents  the  situation  of  arm  between  t\  and  t4,  it  directly  says  something 
about  the  situation  of  a  only  between  ti  and  f3  while  it  never  says  anything  about  the 
situation  of  b.  Otherwise,  we  would  have  to  assume  that  the  state  of  an  inert  object  in 
the  physical  world  changes  just  as  a  consequence  of  an  agent  taking  it  into  consideration. 
Therefore,  the  meaning  of  a  ground  fact  can  change  over  time  with  respect  to  the  different 
system  components:  we  need  additional  indexing  features  in  the  language  to  resolve  this 
ambiguity. 

Finally  we  could  ask  if  the  description  of  the  situation  of  a  system  component  could  not 
be  further  decomposed.  We  could  draw  a  comparison  with  the  way  we  describe  systems  in 
physics;  for  example,  in  order  to  give  the  behavior  of  a  thermo-electro-mechanical  system, 
we  are  required  to  give  a  continuous  function  over  time  for  each  of  the  properties  of  interest 
of  each  component  of  the  system  (e.g.,  the  position  of  a  body,  the  temperature  of  a  mass  of 
gas,  the  electric  voltage  imposed  on  a  resistance).  In  our  B\V  example,  we  could  be  easily 
convinced  that  this  decomposition  in  properties  is  possible.  In  fact,  we  can  describe  the 
input  with  the  only  property  “task  being  executed  by  arm”,  and  the  state  of  each  block 
with  the  situation  of  both  its  top  and  its  bottom. 

5  The  HSTS  Planning  Framework 

In  the  previous  section,  we  have  identified  the  following  requirements  for  a  representation 
language  that  supports  a  modular  description  of  dynamical  systems: 

1.  explicit  declaration  of  the  system  components  and  of  their  dynamical  properties; 

2.  separate  description  of  the  characteristic  of  each  value  for  each  property  to  which  it  is 
associated. 

The  HSTS  planning  framework,  described  below,  satisfies  the  previous  requirements.  The 
framework  consists  of  a  Domain  Description  Language  (HSTS-DDL),  to  specify  the  structure 
of  dynamical  systems,  and  a  Temporal  Behavior  Data  Base  (HSTS-TBDB),  in  w'hich  it  is 
possible  to  build  plans.  For  a  detailed  description  of  the  HSTS  planning  framework,  see  [II]. 

In  HSTS-DDL,  each  system  component  is  represented  as  a  frame;  the  dynamical  proper¬ 
ties  of  the  component  are  slots  in  the  frame.  For  example,  Figure  4  shows  the  prototypical 
system  components  for  B\V. 

To  specify  the  system  in  Section  4,  we  need  one  instance  of  robot-arm  and  two  instances 

of  block. 

Each  property  can  have  one  and  only  one  value  at  any  instant  of  time.  HSTS-DDL 
requires  the  specification  of  the  space  of  all  the  possible  values  that  each  property  can  assume. 
In  HSTS-DDL,  a  value  is  a  tuple;  therefore,  for  each  property  the  space  of  possible  values 


{{ robot-arm 


{{ human-operator 


{{ block 


TASK:  }}  TASK:  }}  TOP: 

BOTTOM:  }} 


Figure  4:  System  components  in  BW . 

<  TOP  (yi),  MOVE  (yi,  y2)  > 

<  TOP  (yi).  CLEAR  (yi)  >,  MEETS 

<  TASK  (robot-arm),  MOVE  (yi,  y2)  >,  CONTAINS 

<  BOTTOM  (yi).  MOVE  (yi,  yi)  >.  EQUALS 

<  TOP  (yi),  CLEAR  (yi)  >,  MET-BY 

Figure  5:  Compatibilities  for  MOVE  of  TOP(block). 

is  a  set  of  relations.  In  BW,  for  example,  the  property  TOP(yi),  where  y\  is  an  instance 
of  block,  can  be  CLEARft/!),  ON(yi, r/2 ) ,  MOVE(t/i, yi),  where  yi  is  either  an  instance  of 
block  or  the  special  symbol  table.  Notice  that,  although  table  is  a  domain  object,  it  is  not 
considered  a  system  component  in  our  description. 

HSTS-DDL  requires  one  to  specify  a  value  descriptor  for  each  pair  <  p,  v  >,  where  p  is  a 
property  and  v  is  a  value.  The  value  descriptor  specifies  two  distinct  pieces  of  information: 
1)  duration;  2)  compatibility  specification. 

The  duration  of  a  value  is  the  temporal  distance  between  its  start  event  and  its  end  event. 
Temporal  distances  are  specified  as  intervals  [d,  D]  (  D  >  d  >  0  )  where  d  is  a  lower  bound 
to  the  distance  and  D  is  an  upper  bound. 

The  compatibility  specification  consists  of  sets  of  compatibilities,  not  necessarily  disjoint. 
Each  compatibility  is  a  temporal  constraint  between  a  property/ value  pair  <  p',v'  >  and 
<  p, v  >.  The  temporal  constraints  used  in  HSTS-DDL  are  equivalent  to  the  temporal 
relations  in  [1]  but  allow  also  the  specification  of  temporal  distances  among  the  extremes  of 
the  intervals  [6]  .  The  meaning  of  a  compatibility  specification  for  <  p,v  >  is  the  following: 
for  each  behavior  6  of  the  system,  if  the  value  v  appears  in  b  on  the  property  p  over  an 
interval  of  time,  then  there  is  a  compatibility  set  in  the  compatibility  specification  such  that 
all  the  compatibilities  in  the  set  are  satisfied  in  6. 

For  example,  our  specification  of  BW  in  HSTS-DDL  will  contain  compatibility  specifi¬ 
cations  relative  to  the  two  pairs: 

<  TASK(robof-arm),  MOVE(t/i,  t/2)  > 

<  TASK( robot-arm),  NO-OP  > 

These  compatibility  specifications  will  contain  compatibility  sets  corresponding  to  those 
in  Figure  3  (a).  The  definition  of  BW  will  also  contain  the  compatibility  set  in  Figure  5. 

We  observe  that  HSTS-DDL  homogeneously  treats  both  input  and  state  properties,  in 
the  sense  that  all  values  of  all  properties  must  have  a  value  descriptor.  This  satisfies  the 
requirement  of  equal  weight  for  input  and  state. 

We  should  not  be  surprised  to  find  more  than  one  property  with  the  same  value  at  the 
same  time.  This  is  analogous  to  what  happens  in  continuous  descriptions  of  the  behavior 
of  physical  systems.  There  the  same  real  number  can  describe  different  things  at  the  same 
time,  i.e.,  the  value  of  different  physical  properties  in  different  measuring  units. 


{{ arm 
TASK: 


TOP: 

BOTTOM: 


NO-OP  | 

CLEAR  (a) 
ON  (a,  table) 


MOVE  (  a,  b) _ |  NO-OP 

|  MOVE  (a,  b)  |  CLEAR  fa) 

|  MOVE  (a,  b)  |  ON  (a,  b) 


}} 


}} 


TOP: 

BOTTOM: 


CLEAR  (b) _ 

_ ON  (b  .table) 


t 


ON  (a,  b) 


}} 


time 


Figure  6:  A  simple  plan  in  HSTS-TBDB. 

The  HSTS-TBDB  is  a  constraint-based  temporal  database  that  extends  the  time  maps 
approach  [6].  At  any  point  in  time,  HSTS-TBDB  can  only  represent  a  set  of  behaviors  of 
a  dynamical  system  specified  in  HSTS-DDL.  The  constraints  allow  one  to  leave  partially 
unspecified  both  the  values  and  the  time  of  occurrence  of  their  start  and  end  events  on 
different  segments  of  the  time  line.  A  planner  working  on  HSTS-TBDB  can  post  and  refine 
constraints  derived  both  from  the  value  compatibilities  and  from  the  additional  conditions 
added  by  the  planning  problem.  As  an  example,  Figure  6  depicts  the  representation  in 
HSTS-TBDB  of  the  same  behavior  of  Figure  3  (b). 

Further  details  on  the  HSTS  planning  frameworks  can  be  found  in  [11]. 


6  Conclusions 

This  paper  addresses  the  definition  of  the  planning  problem  and  the  representational  tech¬ 
niques  that  we  need  to  solve  it. 

Our  definition  of  the  problem  clarifies  its  mathematical  structure  and  is  independent 
from  the  representation  frameworks  over  which  we  can  implement  planners.  Moreover,  our 
approach  helps  to  clearly  distinguish  the  knowledge  about  how  the  world  works  from  the 
heuristic  knowledge  about  how  to  solve  problems  quickly. 

The  HSTS  framework  is  a  general  purpose  facility  consisting  of  HSTS-DDL,  a  description 
language  to  specify  dynamical  models  of  the  world,  and  HSTS-TBDB,  a  constraint-based 
temporal  database  in  which  plans  can  be  built  by  incremental  refinements.  The  HSTS 
planning  framework  solves  the  problem  of  modularity,  one  of  the  keys  to  addressing  large 
“real  world”  applications.  The  demonstration  of  the  effectiveness  of  the  HSTS  approach  is 
an  implemented  scheduling  architecture  that  has  been  successfully  applied  to  the  generation 
of  executable  observation  schedules  for  the  Hubble  Space  Telescope. 
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